feat(pubsub): implement publish hedging to reduce tail latency#13735
feat(pubsub): implement publish hedging to reduce tail latency#13735tonyyyycui wants to merge 12 commits into
Conversation
There was a problem hiding this comment.
Code Review
This pull request introduces a hedging mechanism for the Pub/Sub Publisher, adding HedgeSettings for configuration and a thread-safe HedgeTokenBucket to limit hedged requests. The feedback suggests replacing the synchronized methods in HedgeTokenBucket with explicit ReentrantLock to reduce lock contention and improve performance on the critical path.
| import com.google.common.annotations.VisibleForTesting; | ||
| import javax.annotation.concurrent.GuardedBy; | ||
|
|
||
| /** Token bucket for limiting hedged requests. Thread-safe. */ | ||
| final class HedgeTokenBucket { | ||
| private final int maxTokens; | ||
| private final float refillAmount; | ||
|
|
||
| @GuardedBy("this") | ||
| private float tokens; | ||
|
|
||
| HedgeTokenBucket(HedgeSettings settings) { | ||
| this.maxTokens = settings.getMaxTokens(); | ||
| this.refillAmount = settings.getRefill(); | ||
| this.tokens = maxTokens; | ||
| } | ||
|
|
||
| @VisibleForTesting | ||
| HedgeTokenBucket(int maxTokens, float refillAmount) { | ||
| this.maxTokens = maxTokens; | ||
| this.refillAmount = refillAmount; | ||
| this.tokens = maxTokens; | ||
| } | ||
|
|
||
| /** | ||
| * Attempts to acquire a token for a hedged request. | ||
| * | ||
| * @return {@code true} if a token was acquired, {@code false} otherwise. | ||
| */ | ||
| synchronized boolean tryAcquire() { | ||
| if (tokens >= 1.0f) { | ||
| tokens -= 1.0f; | ||
| return true; | ||
| } | ||
| return false; | ||
| } | ||
|
|
||
| /** Refills the bucket by the configured refill amount, capped at max tokens. */ | ||
| synchronized void refill() { | ||
| tokens = Math.min(maxTokens, tokens + refillAmount); | ||
| } | ||
|
|
||
| @VisibleForTesting | ||
| synchronized float getTokens() { | ||
| return tokens; | ||
| } |
There was a problem hiding this comment.
In performance-sensitive code like the Pub/Sub Publisher, using synchronized methods on the critical path can introduce significant lock contention and performance overhead. To protect shared state while ensuring thread safety and visibility, prefer using explicit locks (such as ReentrantLock) over the synchronized keyword.
import com.google.common.annotations.VisibleForTesting;
import java.util.concurrent.locks.ReentrantLock;
/** Token bucket for limiting hedged requests. Thread-safe. */
final class HedgeTokenBucket {
private final ReentrantLock lock = new ReentrantLock();
private final int maxTokens;
private final float refillAmount;
private float tokens;
HedgeTokenBucket(HedgeSettings settings) {
this.maxTokens = settings.getMaxTokens();
this.refillAmount = settings.getRefill();
this.tokens = maxTokens;
}
@VisibleForTesting
HedgeTokenBucket(int maxTokens, float refillAmount) {
this.maxTokens = maxTokens;
this.refillAmount = refillAmount;
this.tokens = maxTokens;
}
/**
* Attempts to acquire a token for a hedged request.
*
* @return {@code true} if a token was acquired, {@code false} otherwise.
*/
boolean tryAcquire() {
lock.lock();
try {
if (tokens < 1.0f) {
return false;
}
tokens -= 1.0f;
return true;
} finally {
lock.unlock();
}
}
/** Refills the bucket by the configured refill amount, capped at max tokens. */
void refill() {
lock.lock();
try {
tokens = Math.min((float) maxTokens, tokens + refillAmount);
} finally {
lock.unlock();
}
}
@VisibleForTesting
float getTokens() {
lock.lock();
try {
return tokens;
} finally {
lock.unlock();
}
}References
- In performance-sensitive code, prefer using explicit locks over the 'synchronized' keyword to protect shared state while ensuring thread safety and visibility.
There was a problem hiding this comment.
I think this is a valid concern regarding high contention from the use of synchronized for lock synchronization in this class. I'll take a deeper look on Monday at what better options would be.
michaelpri10
left a comment
There was a problem hiding this comment.
At a higher level, I think the full implementation should be one PR (instead of the , given any submitted changes become public. It would be unexpected for customers to be able to set HedgingSettings without anything actually happening, so the final PR should have everything needed for the implementation included.
| /** Settings for configuring publish hedging. */ | ||
| public final class HedgeSettings { | ||
| /** Default hedging delay. */ | ||
| private static final Duration DEFAULT_DELAY = Duration.ofMillis(100); |
There was a problem hiding this comment.
As a note, this value will be changing (potentially other default values as well). Leaving this as a placeholder comment to ensure these meet the agreed upon values before merging.
| * | ||
| * @return the hedging delay. | ||
| */ | ||
| public Duration getHedgeDelay() { |
There was a problem hiding this comment.
nit: Does this method need to be public? I think leaving it without an access modifier (i.e., making it package-private) should be sufficient.
There was a problem hiding this comment.
I've removed it for now, but I think it would also make sense if the user could see what they see the hedge delay is set to since it's a configurable field. Leaving this conversation unresolved.
| import com.google.common.annotations.VisibleForTesting; | ||
| import javax.annotation.concurrent.GuardedBy; | ||
|
|
||
| /** Token bucket for limiting hedged requests. Thread-safe. */ | ||
| final class HedgeTokenBucket { | ||
| private final int maxTokens; | ||
| private final float refillAmount; | ||
|
|
||
| @GuardedBy("this") | ||
| private float tokens; | ||
|
|
||
| HedgeTokenBucket(HedgeSettings settings) { | ||
| this.maxTokens = settings.getMaxTokens(); | ||
| this.refillAmount = settings.getRefill(); | ||
| this.tokens = maxTokens; | ||
| } | ||
|
|
||
| @VisibleForTesting | ||
| HedgeTokenBucket(int maxTokens, float refillAmount) { | ||
| this.maxTokens = maxTokens; | ||
| this.refillAmount = refillAmount; | ||
| this.tokens = maxTokens; | ||
| } | ||
|
|
||
| /** | ||
| * Attempts to acquire a token for a hedged request. | ||
| * | ||
| * @return {@code true} if a token was acquired, {@code false} otherwise. | ||
| */ | ||
| synchronized boolean tryAcquire() { | ||
| if (tokens >= 1.0f) { | ||
| tokens -= 1.0f; | ||
| return true; | ||
| } | ||
| return false; | ||
| } | ||
|
|
||
| /** Refills the bucket by the configured refill amount, capped at max tokens. */ | ||
| synchronized void refill() { | ||
| tokens = Math.min(maxTokens, tokens + refillAmount); | ||
| } | ||
|
|
||
| @VisibleForTesting | ||
| synchronized float getTokens() { | ||
| return tokens; | ||
| } |
There was a problem hiding this comment.
I think this is a valid concern regarding high contention from the use of synchronized for lock synchronization in this class. I'll take a deeper look on Monday at what better options would be.
This PR implements publish hedging in the Java Cloud Pub/Sub Publisher. Specifically, it adds support for scheduling "hedged" publish attempts when a publish call is slow to respond. A token-based method is utilized to rate-limit hedged requests and a coordinator is used to manage/cancel concurrent requests to prevent duplicate publishes.